前言

大家好，我是一名醫療資訊相關科系的學生。

在學習醫療資訊以及接觸醫院資訊工作的過程中，我經常聽見「電子病歷」、「醫療資料交換」、「API」、「HL7」和「FHIR」等名詞。雖然知道它們與醫院資訊系統有關，但如果要進一步解釋FHIR到底是什麼、如何交換資料，我其實還沒有辦法完整回答。

因此，我決定利用這次30天鐵人賽，從初學者的角度認識FHIR，並將每天學到的內容整理成文章。

這個系列不只是要介紹名詞，後續也會使用JSON、REST API和Postman進行實際操作，希望30天後，我不只能說出FHIR的定義，也能真正看懂並操作基本的FHIR資料。

為什麼會選擇FHIR？

醫院裡並不是只有一套資訊系統。

病人從掛號、看診、接受檢查、領藥到最後批價，可能會接觸到不同的系統，例如：

• 醫院資訊系統（HIS）
• 電子病歷系統（EMR）
• 檢驗資訊系統（LIS）
• 醫療影像資訊系統（PACS）
• 藥局資訊系統
• 掛號及批價系統

這些系統分別儲存不同的醫療資料，但它們又必須互相交換資訊。

例如，醫師開立一張抽血檢驗單後，檢驗系統需要收到醫令；檢驗完成後，結果也要傳回醫師使用的系統。假如每套系統使用的資料格式都不同，系統之間就很難正確溝通。

這時候，我們就需要一套共同的資料交換標準，而FHIR正是目前重要的醫療資料交換標準之一。

FHIR是什麼？

FHIR的全名是：

Fast Healthcare Interoperability Resources

FHIR是由HL7所制定的醫療資料交換標準。

它將醫療資料拆分成不同的「Resource」，也就是資源。每一種Resource負責表示特定類型的醫療資訊，例如：

我們可以先把FHIR Resource想像成一塊塊具有統一格式的積木。

Patient是一塊病人資料積木，Observation是一塊檢驗結果積木，Encounter則是一塊就醫紀錄積木。不同系統只要遵循相同的規則，就比較容易辨認、交換及使用這些資料。

FHIR Resource可以使用JSON或XML等格式表示，也經常搭配RESTful API進行交換。對於剛開始學習Web與API的學生來說，JSON格式相對容易閱讀，因此這個系列將以JSON作為主要示範格式。

下面是一份經過簡化的Patient資料：

{
  "resourceType": "Patient",
  "id": "patient-001",
  "name": [
    {
      "text": "王小明"
    }
  ],
  "gender": "male",
  "birthDate": "2000-01-01"
}

即使還沒有正式學過FHIR，我們也可以從這段資料大致看出：

• resourceType表示這是一筆Patient資源。
• id是這筆資源的識別碼。
• name是病人姓名。
• gender是病人的性別。
• birthDate是病人的出生日期。

當然，真正的FHIR Patient Resource還有更多欄位和使用規則，後續文章會再逐步拆解。

這30天預計會學習什麼？

本系列將分成五個階段。

第一階段：認識醫療資料交換

前幾天會先了解醫院有哪些資訊系統，以及不同系統為什麼需要交換資料，接著認識HL7與FHIR的基本概念。

第二階段：看懂FHIR資料

這個階段會介紹：

• FHIR Resource
• JSON資料格式
• 常見資料型別
• Resource之間的Reference
• 醫療標準代碼

第三階段：操作FHIR REST API

接著會使用Postman實際送出API請求，包括：

• GET讀取資料
• POST新增資料
• PUT更新資料
• DELETE刪除資料
• 搜尋Patient
• 查看Bundle搜尋結果

所有操作都會使用虛構資料或公開測試資料，不會使用任何真實病人的個人資料。

第四階段：認識常見醫療Resource

這個階段會進一步介紹：

• Patient
• Observation
• Encounter
• Condition
• MedicationRequest

並透過簡單的醫療情境，了解它們分別負責記錄哪些資訊，以及如何互相連結。

第五階段：認識臺灣FHIR應用

最後會認識臺灣核心實作指引TW Core IG，並建立一個簡單的虛構門診情境，把Patient、Encounter、Observation、Condition及MedicationRequest串在一起，作為30天的學習成果。

預計使用的工具

這次挑戰預計會使用下列工具及資料：

1. FHIR官方規範

查詢FHIR Resource的定義、欄位及RESTful API規則。

2. 臺灣核心實作指引

了解FHIR如何依照臺灣的醫療環境與資料需求進行調整。

3. Postman

用來送出API請求及查看FHIR Server回傳的JSON資料。

4. 公開FHIR測試伺服器

練習讀取、搜尋及建立測試資料。實際使用前，也會先確認伺服器支援的功能與相關規則。

我希望30天後可以做到什麼？

我替自己設定了幾個學習目標：

1. 能用自己的話解釋FHIR是什麼。
2. 能辨認幾種常見的FHIR Resource。
3. 能看懂基本的FHIR JSON資料。
4. 能理解GET、POST、PUT和DELETE的差異。
5. 能使用Postman操作FHIR API。
6. 能將病人、就醫、檢驗、診斷及用藥資料串聯起來。
7. 能初步認識臺灣的TW Core IG。

我現在對FHIR仍然處於初學階段，因此這個系列也會是一份真實的學習紀錄。如果文章中有理解不完整或需要修正的地方，也歡迎大家提出建議。

希望透過接下來30天的整理，我可以逐漸把原本陌生的技術名詞，轉化成自己真正理解並能夠操作的知識。

今日小結

今天先說明了我選擇FHIR作為鐵人賽主題的原因，也簡單認識了FHIR、Resource，以及接下來30天的學習方向。

目前可以先把FHIR理解成：

一套協助不同醫療資訊系統，以共同方式表示及交換醫療資料的標準。

FHIR的內容其實非常龐大，因此這30天不會追求一次學會所有規範，而是從最基礎的觀念開始，一步一步認識常見Resource與API操作。

下一篇將從病人實際看診的過程出發，看看一筆病人資料會經過哪些醫院資訊系統。

明日預告

Day 2｜一筆病人資料在醫院裡如何流動？

參考資料

1. HL7 FHIR R4 官方規範
   https://hl7.org/fhir/R4/

2. HL7 FHIR R4 架構說明
   https://hl7.org/fhir/R4/overview-arch.html

3. 衛生福利部臺灣核心實作指引（TW Core IG）
   https://twcore.mohw.gov.tw/ig/twcore/